[[분류:인천과학고등학교/사건사고]] [include(틀:한시적 넘겨주기, 설명1=사건의 주동자, 문서명1=엄지오(32기))] == 개요 == [[엄지오(32기)]]의 디도스로 인곽위키가 장장 1일동안 멈추었던 사건이다. == 원인 == == 결과 == [[엄지오(32기)]]는 영구 밴을 '''또''' 먹을 예정이다. ==[[엄지오(32기)]]의 반박== > 애초에 내가 아침에 요청 보낸건 상관없고 내가 요청 끝냈을때 서버 멀쩡했음 > 몇시간 후에 1면때 희진쌤이 실수로 정보실에 있는 서버컴 꺼서 꺼진거임 > 증인: 김규원 김도훈 희진쌤 [* '''하지만''' 그 다음 꺼진 것이 김준서랑 이도혜가 동시에 커밋하다가 충돌났다는 말은 반은 맞고 반은 틀리다. 당일 오후 7시에 바로 수정하여 커밋을 올리고 김준서의 노트북으로 잘 돌아갔으나 갑자기 김준서의 추가적인 최적화 안된 커밋으로 에러가 뜬 것이다.][* 앞의 주장도 살짝 애매한게 김준서의 커밋도 개인 노트북상 잘 돌아갔다. 아직 정확한 원인을 모른다.] ===기술적인 반박=== 인곽위키의 조회수 증가 로직을 보면, 내가 그때 초당 1~2회 수준의 /api/v2/page_view 요청을 계속 보냈는데, 디도스라고 하는 것은 개쌉오바를 떠는거라고 볼 수 밖에 없음ㅇㅇ 디도스는 말 그대로 서비스 거부를 일으킬 정도의 과도한 트래픽이나 분산된 요청을 뜻하는데, 애초에 디도스 할거면 초당 몇천개씩 보냈겠지 그리고 내가 보낸 요청은 애초에 일반적으로 문서 보는것처럼 전체 문서 페이지(/w/...)를 계속 새로고침하는 것도 아님. 그냥 문서 페이지를 열면 서버는 먼저 문서 원문을 가져오고, 렌더링을 수행한 뒤, 마지막에 별도로 조회수 증가 API를 호출함. 근거: route/view_w.py의 320행, route/view_w.py의 336행. 코드는 깃허브에서 알아서 보셈 ㅇ 다시 말해 /w/... 전체 요청은 “문서 조회 + 렌더 + HTML 생성 + 조회수 증가”까지 모두 포함하고 있음. 근데 나는 /api/v2/page_view/... 를 직접 호출해서 그보다 훨씬 좁은 처리 경로만 이용했음. 따라서 /api/v2/page_view 2 req/s를 /w/... 전체 페이지 2 req/s와 같은 무게로 보는 것도 오바임... 그리고 애초에 1초에 2번 요청도 못받으면 그게 서버임?? 그리고 Python 레이어의 구현도 이를 뒷받침한다고 볼수있음ㅇ. 조회수 API는 Python에서 자체적으로 무거운 비즈니스 로직을 처리하는 것이 아니라, 문서명을 받아 내부 Go 프로세스로 전달하는 브리지 역할임. 근거: route/go_api_w_page_view.py의 3행, route/tool/func.py의 150행. 그러니까 이 경로는 구조적으로 내부 서비스에 넘겨서 카운트만 갱신하는 단순 경로라고 할 수 있음. 내가 매 요청마다 권한 계산이나 대규모 데이터 가공을 수행같이 복잡한거 시킨것도 아니고 단순한 요청만 보냈는데 진짜 뭐가문제임?? 추가로 데이터베이스 부분도 함께 보자면, 인곽위키는 SQLite를 사용하지만, 초기화 시 WAL 모드를 설정함. 근거: route/tool/func.py의 258행, app.py의 130행. 여기서 WAL은 Write-Ahead Logging의 약자인데 이게 뭐냐면 데이터를 곧바로 원본 파일에 덮어쓰는 대신 먼저 “변경 내역을 별도의 로그 파일에 기록한 뒤 나중에 반영하는 방식”인데 이 방식의 장점은 읽기와 쓰기가 동시에 일어날 때 충돌을 줄여 준다는 점임. 일반적인 SQLite 기본 모드보다 동시 접근에 더 유리해가지고, 반복 요청이 곧바로 치명적인 DB 장애로 이어지는 가능성을 낮춰 줌... 물론 WAL이 모든 문제를 해결하는 것은 아니긴해도 인곽위키가 WAL을 쓰고있는데, 그리고 2 req/s 수준의 저속 요청 밖에 안보냈는데, 이것때문에 사이트 다운됐다고 하기엔 좀 양심이.. 애초에 2 req/s로 한시간 반 정도밖에 안했음 그리고 위키 스파게티 코드문제 한두번 터지는 것도 아니고 실검 로직 이상하대서 실검 띄워지는지 해본건데 갑자기 몇시간 후에 책임 나한테 돌리는거부터 어이가 없음 ㄹㅇ ===결론 및 요약=== 내 탓 아님 밴이나 푸셈 첫째, 내가 요청을 마쳤을 당시 서버는 정상 동작 중이었다. 둘째, 요청량 자체도 디도스라고 부를 수준의 폭주성 트래픽과는 거리가 있었다. 셋째, 희진쌤이 서버컴을 껐다. ==[[엄지오(32기)]]의 주장에 대한 [[최희진(교사)]]의 입장표명== 그 당시 노트북을 닫지 않았다! 인곽위키가 되지 않는다 노트북을 켜야 한다는 말을 듣고 노트북을 확인했다. 노트북 화면이 절전모드로 들어가 까만 것을 꺼진 것으로 착각하고 전원 버튼을 눌러서 꺼졌으나, 다시 켰다... == [[엄지오(32기)]]의 주장에 대한 반박 == 저거 일단 AI 써서 자기 무관하다고 한거 같은데, 절대 아니다. 사실 디도스라는 표현 자체는 틀린게 맞는데[* 정확한것은 낮고 느린 공격이며, 사실상 느리게 한다는것 빼고는 서버에 과부하를 주는 디도스와 다를바가 없다.] 결론적으로는 엄지오 때문에 일어난 일은 맞다. 서버에서 실검 처리하는 방식이 로그를 하나하나 다 본 다음에 갯수 세는 방식[* 지금은 아니다.]인데, 엄지오가 거기에 얼마나 많은 리퀘를 보내놓아서 터진거이다. 추가로 에러 뜬게 524에러인데, 이게 100초 타임아웃 에러임, 즉 동기 방식의 실검을 위해 사이트를 불러오는 과정에서 엄지오의 그 많은 로그를 하나하나 서버가 보다가 100초가 넘어서 뒤진거이다. 희진쌤이 서버컴을 꺼서 인곽위키가 닫히면 다른 에러가 떠야한다. ==재반박== 에러 524 아니라 1103임 ㅅㄱ 그리고 내가 요청 끝냈을땐 멀쩡했다니까 몇번을 말하냐 ㄹㅇ 니네 코드 수정하다가 맛간거라고 ===재반박에 대한 재반박=== 에러 1103은 꺼진거고 524는 타임아웃인데, 524에러가 났었다. 애초에 1103은 524이후에 일어났다. 코드 수정하다가 맛 간게 아니고 코드 수정하기전에 맛가서 수정했겠지, 상식적으로 생각해도 업데이트할 일이 없었는데 수정을 왜했겠냐. ====재반박에 대한 재반박에 대한 재반박==== 실검 업뎃[* 이는 커밋 시각을 보면 사실관계가 맞지 않음을 알 수 있다.]이랑 도깨비불 현상[* 아직 반영도 안했다.] 고쳐서 업뎃했잖아 뭔 === 요약 === [[이도혜(32기)]]의 기깔난 코드와 [[엄지오(32기)]]의 행동으로 인곽위키 서버가 맛탱이가 가버림. 지금 이렇게 쾌적한 이유도 7일에서 하루로 줄여서 이제 1만개 로그 안봐서 그런거임.~~7일이든 하루든 차피 하루만에 만개보내서 터졌다고 주장할거면 줄인게 뭔상관임(진짜모름)~~[* 그 짓거리 한게 일주일은 안지났지만 하루는 지났기 때문이지] 밴은 아직 안풀거긴함.[* 자숙해라, 애초에 인위적으로 조회수 올리는거 부터가...]
